Modern Multifunction Peripheral (MFP) devices have the ability to process multiple page and/or multiple copies at high speeds. More specifically, these devices are able to print the second page and/or second copy at or near the rated print engine speed.
These machines still have a problem obtaining optimum engine performance when printing a continuous stream of single copy-single page jobs, or any print job with a low-number of pages. Few printing devices are effective in job streaming or continuous Raster Image Processing (RIP) for low-page count print jobs.
FIG. 1A shows the traditional operation of an MFP device 12. The MFP device 12 handles the processing of a print job 13 using a channel selector 14, input pipe 20, sniffer 18, and one or more print data interpreters 22, 24 and 26. The print data interpreters can include a PJL interpreter 22, a Page Description Language (PDL) or Printer Control Language (PCL) interpreter 24, or a PDL or Post Script (PS) interpreter 26.
The channel selector 14 arbitrates the selection of the print jobs 13. The print jobs may be transmitted via a serial input device and multiple print jobs may be pending on multiple different input channels. For example, print jobs may be received over a parallel, serial and/or USB port, LPR port from a host 1 and a LPR port from a host 2, etc. Print jobs may also be received over wireless ports, such as IrDA, Bluetooth and Wi-Fi.
The channel selector 14 reads the data from the selected channel and buffers the data into an input buffer 16, which may be Random Access Memory (RAM). In some cases, the input buffer 16 is sufficient to hold the entire print job 13. In other situations, the print data must be buffered in chunks in input buffer 16 as previously stored chunks of print data in buffer 16 are processed by the MFP 12.
When a new print job is detected by the channel selector 14, and the first block(s) of print data are buffered in input buffer 16, the channel selector 14 initiates the sniffer 18 to pre-read (i.e., non-consumed) the first buffered data block. The sniffer 18 analyzes the first bytes in the buffered print data from the new print job to determine the print language type such as, PJL, PCL, Portable Document Format (PDF), Postscript, etc. The sniffer 18 invokes the print language interpreter 22, 24 or 26 associated with the identified print language and informs the input pipe 20 which interpreter 22, 24, or 26 to direct the data blocks for the new print job. This process is generally referred to as auto-language switching.
In FIG. 1B, print jobs are typically generated by a printer driver, that converts document/image data into printer ready data. One class of printers 12, sometimes referred to as ASCII printers, support industry common print data languages such as PJL, PCL, Postscript, and PDF. Print jobs generated for these devices from their associated printer drivers are typically constructed with the following sequence:                1. UEL—Universal Exit Language.        2. Printer Job Language (PJL) sequence to indicate the spooling of a print job (i.e., single RIP).        3. PJL sequence for job-wide settings.        4. PJL sequence for explicit language switch to a page description language (PDL).        5. PDL data for the page-settings and page data.        6. UEL—Universal Exit Language.        7. PJL sequence to indicate the end of the spooling of a print job.        
When the UEL sequence is encountered, the printing device 12 configures itself to start the processing of a new RIP. Following the UEL, the sniffer 18 (FIG. 1A) detects the presence of PJL commands and informs the input pipe 20 to direct the remaining input data to PJL interpreter 22. The PJL interpreter 22 interprets the PJL command sequences, which generally result in configuring job-wide settings for the current print job context, such as setting environmental parameters for an options manager 28. The PJL sequence typically ends with an explicit language switch (i.e., @PJL ENTER LANGUAGE=<PDL>). This instruction informs the input pipe 20 that the print data type for the remaining print data has changed to PDL. The PJL interpreter 22 then terminates processing. The PJL sequence may also not end with an explicit language switch, but merely be followed by commands in a PDL format. In this case, when the PJL interpreter encounters a non-PJL formatted statement, the subsequent print stream is passed back to the sniffer 18 to initiate an automatic language switch for the remaining print data.
Referring to FIG. 1C, upon receipt of the explicit language switch from the PJL interpreter 22 or automatic language switch from the sniffer 18, the input pipe 20 invokes the associated PDL interpreter 24 (e.g., PCL) and redirects the remaining input data to the corresponding PDL interpreter 24. The PDL interpreter 24 processes the PDL data to construct page images. Print job processing may be controlled by one or more job-wide settings 30 set in the options manager 28 by the PJL interpreter 22 (FIG. 2B), and further controlled by subsequent job-wide settings and page-specific settings specified in the PDL data.
The PDL interpreter 24 may produce page images as follows:                1. Syntactical analysis of the PDL data.        2. Semantic analysis of the PDL data.        3. Convert the PDL data into an unrendered intermediate representation, referred to as a Display List (DL) 32.        
The print system described above does not initially fully process the print data. Instead, the print system processes the print data just enough to verify that the data is valid (syntactic and semantic) and converts the data into a format efficient for subsequent rendering.
In FIG. 1D, the PDL interpreter 24 completes consuming all of the remaining print data for example when an End Of File (EOF) condition is detected indicating the end of the job's spool data. The PDL interpreter 24 sends back an acknowledgement message 34 to the channel selector 14 indicating that the print job was successfully processed such as by being converted to the display list 32. Depending on the type of printing protocol handling, the channel selector 14 may then send back a successful job completion acknowledgement message to the host device, release the connection on the channel, and proceed to arbitrate the next print job on one of the available input channels.
In FIG. 1E, the PDL interpreter 24 typically encounters at least one UEL 21 before the end of the input data for the print jobs formed by an associated printer driver. The UEL 21 notifies the PDL interpreter 24 of a RIP segment boundary. The subsequent print data following the UEL 21, if any, may be processed by a different PDL interpreter(s). Note, the print data from a single print job may contain more than one RIP segments. If the UEL 21 is at the end of the input data (i.e., EOF), the PDL interpreter 24 sends a message to the rendering process 25 that the last DL element has been generated for this RIP segment, and returns control back to the input pipe 20 and sniffer 18.
In FIG. 1F, the rendering process 25 includes a RIP operation 40 that converts the DL data 32 into RIP images, which are then placed on a RIP queue 42. The rendering process 25 generally is asynchronous and may begin processing as the DL elements 32 are being generated. Some operations of the rendering task 25 may be further controlled by job-wide settings (e.g., copies, collation, post-collation finishing, document filing) specified by the print job options manager 28. The RIP images are then sent from the RIP queue 42 to the print engine 44.
When the above channel selection, interpreter and rendering processes switch from processing one RIP segment to another RIP segment, a substantial time delay may occur. The time delay occurs even when the RIP segments are in the same spool file or the same print job. These delays may be a combination of software (e.g., reallocation of buffers, font unloading/reloading etc.) and hardware processes (e.g., engine cycle down, media/output path roller shutdown/startup changes, etc.).
These inter-RIP delays are undesirable when the printing device receives a continuous stream of back-to-back jobs. This delay is particularly undesirable for small page count jobs when none of the job differences such as job-wide settings and PDL interpreter would result in inter-RIP conflicts. An inter-RIP conflict refers to a subsequent RIP segment that cannot be processed in the same context of the previous RIP segment.
Therefore, there is a desire for a more effective method for printing back-to-back print jobs that do not have inter-RIP conflicts as a continuous RIP.